Can Web Services Scale Up?

I n the past, only major Internet players such as Amazon, eBay, and Google were interested in deploying large-scale Web services. However , this is changing rapidly—all sorts of companies and governmental organizations are suddenly looking towards Web services as a platform that might support a wide range of demanding applications. Examples of such systems include big banking and brokerage data centers , online service centers for companies that operate on a global scale, systems that operate critical infra-structures like electric power and transportation, and government and military systems responsible for everything from intelligence gathering to issuing Social Security checks. This emerging trend presents developers with a new challenge: building Web services solutions that scale. In a nutshell, a scalable system is one that can flexibly accommodate growth in its client base. Such systems typically run on a clustered computer or in a large data center and must be able to handle high loads or sudden demand bursts and a vast number of users. They must reliably respond even in the event of failures or reconfigura-tion. Ideally, they're self-managed and automate as many routine services such as backups and component upgrades as possible. Many settings also require security against attempted intrusions and distributed denial-of-service (DDoS) attacks. At a glance, today's Web services standards seem to answer these needs. However, a more probing analysis reveals many critical limitations. CURRENT LIMITATIONS Consider, for example, the major Web services standards dealing with reliability: WS-Reliability and WS-Transactions. WS-Reliability provides for reliable handoff between a client system and a queuing system residing between the client and some service. However, the standard isn't nearly as comprehensive as the name implies; rather, it's limited to pipelines that include queuing subsystems. WS-Reliability boils down to a few options that a client can use to tell the queuing system whether or not to reissue a request if a failure occurs, and a way to time-stamp requests so that a service can detect duplicates. WS-Transactions actually consists of two side-by-side standards: One is aimed at applications that perform database transactions with the usual ACID (atomicity, consistency, isolation , durability) properties; the second builds on the first and supports a way to build " scripts " of simpler transactions. Some might argue that all reliability needs can be recast in terms of transactions. However, the past three decades have seen one failed attempt after another to build everything over a database …